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(54) Abstract Title 

Method for checking a computer system's configuration 
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(57) The configuration of a computer system is checlced 
by providing a file with the required configuration or 
specification, deriving a second check file by testing the 
computer's configuration and comparing to two files to 
approve the computer. The check file could include 
details of the system's hardware, firmware and software. 
Also the check files could comprise checksum data for 
the software components. Also disclosed are a computer 
program, method of manufacturing a computer and a 
method of checking a computer after Installation. 
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METHOD FOR CHECKING A COMPUrTER SYSTEM CONFIGORATION 

Fxeld. Of The Invention 

This invention relates to a method for checking a 
computer system configuration, and in particular for 
5 verifying either a software configuration, or a firmware 
configuration, or a hardware configuration, or any 
combination of these. 

Background -bo the Invention 

Computer systems of all types have increased greatly 

10 in complexity in recent years. One result of this 
increase in complexity is the tailoring of hardware, 
software and firmware configurations of computers to 
particular end users. This now happens with all types of 
computer including PCs and servers . 

15 When a user orders a computer a particular 

configuration is specified. This will comprise a 
hardware configuration, firmware in which reside many of 
the basic routines required to make the hardware run, and 
a software configuration or a software stack which 

20 includes all the software the user specifies including 
the particular operating system he wishes to use, any 
optional modules to that operating system to give 
particular types of enhanced functionality and usually a 
number of application programmes which run within the 

25 operating system. 

The hardware configuration comprises a number of 
components, some of which have optional settings which 
are set at the factory when the computer is manufactured 
to conform with a particular user's requirement. 



The firmware comprises a number of components, 
mostly memory units of the read only type pre-loaded with 
software to run various routines operations on the 
hardware configuration, in dependence on the hardware 
configuration selected. The software configuration 
usually includes an operating system for the hardware and 
a number of application programmes. These are contained 
as a software stack which usually resides on a hard disc 
in the computer system. These programmes are stored in 
files on the hard disc or other storage medium. 

At present, there are no tools available for 
checking at the point of manufacture whether or not a 
hardware, firmware, or software configuration has been 
correctly installed to fulfil a customer's requirements. 
With the fast rate of development of computer technology 
this can lead to installation errors in the 
configurations for example incompatibility between a 
software file and the latest version of a particular 
version of hardware. If these are not picked up at 
manufacture, they do not become apparent until a computer 
system is installed at its end destination and use of it 
is commenced. Even then, some parts of the configuration 
are not accessed particularly frequently and it therefore 
may be some time before the error is detected. 

Summary of the Xnven'txon 

Data for checking that a hardware configuration is 
correctly installed usually comprises a data file or set 
of data files including data identifying the particular 
pieces of hardware which should be installed in a 
configuration and any factory settings which should be 
applied to the hardware. 



Software and firmware can include relatively large 
files storing routines and applications to be executed on 
the computer system. Providing a corresponding file 
against which to check a particular configuration would 
require a large amount of storage and, furthermore, a 
significant amount of time to compare all the files 
installed in the configuration against a baseline 
configuration. 

Accordingly, Sun Microsystems^ has developed a tool 
known as a fingerprint database which is publically 
available and contains checking data including checksxams 
for all files available in Sun packages, A checksum is 
a value derived using digital logic from the data stored 
in a file. Checksums have been well known for many years 
as a way of verifying digital data. The size of a 
checksum need bear no relation to the size of the data 
file from which it is derived. In their simplest forms, 
checksums are single bits added to the ends of data 
wr. :ds. In more sophisticated forms, they will comprise 
a ^iuv. ality of bits or words added to data. The use of 
cJe'-cksums to verify the integrity of a data file requires 
reLativ*=^ly little storage compared to the size of the 
fxj.v. What is required is a microprocessor or some form 
of digital logic to perform the checksum calculation on 
the vile being checked to determine a checksum or 
compax/son with a known checksum for that file. Many 
computer systems arc capable of running this type of 
checking operation o?.^ "^heir own configurations. 

To date, th»^i 7 '..:i_.:cjcprint database including all the 
checksums for Sian ^^.icrosystems Inc has not been used in 
manufacture . 

In a specific embodiment of the present invention, 
a check file is derived for each computer system 
configuration to be produced. The check file is then 
used to check the configuration of the computer system to 
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which it relates at the point of manufacture. The check 
file can also be supplied to a customer and when a 
computer system is installed at a customer's site, the 
check file can be compared against a check file derived 
from the computer system configuration to determine 
whether or not there are any inaccuracies in the 
configuration . 

The check file can be used to check hardware 
configuration, firmware configuration, or software 
configuration or any combination of these. 

The check file is originally generated when the 
computer system configuration is defined. It is derived 
directly from the configuration. If a fingerprint 
database is available containing checksums for all files 
available, this can be accessed to construct the checK 
file. If such a database is not available then checksums 
from data files can be derived using digits] logic, and 
predetermined checksiam routines. 

At manufacture, embodiments of this invention enable 
20 a variety of computer system configurations to be checked 
simultaneously whilst they are still in the factory. 
This can be the checking of a plurality of identical 
configurations or of different configurations. A copy of 
the check file for each configuration, can also be 
25 supplied with each computer system delivered to each end 
user and a further verification of the integrity of the 
configuration performed either by the end user or by an 
installation engineer before the system comes into 
operation . 

Computer systems can be arranged to check their own 
configurations using the check file, or, alternatively, 
a further computer system can be used to compare the 
configuration of the computer system against the check 
file- 



30 
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Birxef Descr±p'tion o£ the Drawxzigs 

Specific embodiments, of the invention will now be 
described in detail by way of example with reference to 
the accompanying drawings in which : 
5 Figure 1 shows schematically the relationships 

between hardware, firmware, and software in a computer 
configuration; 

Figure 2 shows schematically the production of a 
particular configuration from the customer requirements 
- 10 stage through to a customer installation being in place; 

Figure 3 shows how at the engineering stage a check 
file is produced in an embodiment of the invention; 

Figure 4 shows the quality assurance processes 
applied to the check file and configuration generated in 
15 figure 3 in an embodiment of the invention; 

Figure 5 shows the manufacturing checking processes 
applied using the check file generated in figure 3; and 

Figure 6 shows the checking processes performed at 
a ci. v' 'w;.^-r installation* 

20 : ed urxp'bxon o£ Pxefexxed Bmbodxmexi'bs 

Ir figure 1, a computer configuration is shown. 
This co-uprises a hardware configuration 10, a firmware 
configure ..ion 12 and a ooftware stack 14. Each of these 
three portions of the noi). figuration are in communication 

25 with each otii'^^r. :\n .scribed above, the hardware 

configuration u )iupr 5 all the hardware elements 
required to meet a particular customer requirement^ the 
firmware conf iguratioxi comprises the routines required to 
make the particular hardware configuration run, and is 

30 normally stored in some form of read-only memory. The 

software stack comprises a set of files which will 
typically include an operating system and a set of 
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application progranaaes which are required by the customer 
to run on the hardware. 

Figure 2 illustrates the flow from a customer's 
requirements being specified at 16 through to the 
customer installation at 18. Customer requirements are 
firstly provided to an engineering department at a 
manufacturer which designs a hardware, firmware, and 
software configuration at 20 to meet the particular 
customer requirements . At the same time, a check file is 
generated which includes listings of all the harciware 
items considered appropriate, the firmware requirements, 
including pre-loaded routines, and data derived from the 
files comprising the software stack 14. The hardware 
listings include part numbers and details of optional 
settings to the hardware. The firmware listing also 
include part numbers, but also inclv-de checksum data 
derived from routines stored in firmware. The data 
derived from the software stack includes checksum dato. 
This is data derived logically from the bits comprising 
the file using known techniques. The checksum data for 
a file will require a much smaller amount of storage than 
the file itself. Checksiam data can also be derived from 
the routine stored in firmware. 

At Sun Microsystems, a fingerprint database is 
available which stores checksum files for every 
application programme or software routine produced by Sun 
Microsystems. Usually, the engineering department will 
access this database to compile the check file using the 
; checksums for each file in the software stack or routine 
30 Stored in firmware. 

The process then passes to a quality assurance 
department 22 which compiles a check file from the 
configuration supplied. It does this by checking the 
hardware present and any particular settings of this 
hardware, checking the firmware installed and deriving 
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checksim data from routine stored in firmware, and 
deriving checksum data from the files in the software 
stack. The checksum dat is derived from first 
principles using the same r atines as should have been 
used at the engineering stac 20. 

Once the configuration' has been approved by the 
quality assurance departme it 22 it passes to the 
manufacturing department 24 .vhich builds the particular 
configuration. After build: ig the configuration it also 
generates a check file frcr first principles using the 
same checksum logic as used y the engineering department 
and quality assurance depa.tment. This check file is 
compared against the oric ^nal check file and if it 
corresponds the computer i-: released to a customer. 

At a customer instal ..ation 18, a check file is 
generated again from firs- : principles using the same 
checksLun logic as used in he earlier stages and if the 
check file generated corre:i :onds to that from the earlier 
ij'S-igos, the installation i. approved. 

The >^.xC'jess shown at :0 in figure 2 is illustrated 
in more detail in figure 3. In this^ a customer's 
requiremeit IS ar(^. receiv^a and a configuration to meet 
these reqi . reiTients is des igned at 26. A check file is 
then compilftd at 28. Thi::? is derived from the hardware 
specified hj the configuration and its settings, the 
firmware specified and r.he software stack specified. 
Routines stored in firmt.«crre will have checksum data in 
the check file and each f , le \n the software stack will 
also have checksuir. c^\ta f .It stored in the check file. 
The checksura data in a«': organisation such as Sun 
Microsystems is read directly to the check file from a 
fingerprint database which stores checksum data for all 
files available within Sun Microsystems- Once the check 
file has been compiled at 28, it and the configuration 



?.re output at 30 and can be supplied to the quality 
assurance department 22. 

At the quality assurance department, a new check 
file is derived from the configuration specified. This 
check file comprises the data relating to the hardware 
configuration and settings applied thereto, data relating 
to the firmware, including checksum data for routines 
stored therein, and checksxjin data derived from the 
software stack. Checksum data is derived from first 
principles from the configuration using the same checksuni 
routines as were originally used to derive the checksiom 
data stored in the fingerprint database 32. This takes 
place at step 34- 

Once the new check file has been compiled, it is 
compared against the original check file compiled by the 
engineering department at 36. If the check files passes 
the comparison test then the configuration and checs* tile 
are authorised for manufacture at 38 and are released to 
the manufacturing department. 

If the comparison test is not passed, a listing of 
errors is provided at 40 and these are returned to the 
engineering department at 20 to check the configuration 
against that specified and to ensure that the errors 
detected are corrected either by respecifying the 
configuration or by correcting the check file. 

The manufacturing process is shown in figure 5, and 
in this, the configuration specified is built at 42. At 
a check file is derived from the built configuration 
Ing first principles by examining the hardware in the 
configuration and the settings applied thereto, examining 
the firmware and the routines stored therein, and by 
examining the files stored in the software stack. 
Checksum data is derived from the routines stored in 
firmware and from the files in the software stack. 



The check file is compiled using an external 
computer which runs the routines required to generate the 
check file from the configuration that has been built - 
Alternatively the check file can be generated directly by 
the computer system that has been built using a software 
diagnostic that runs the routines to generate the check 
file. 

The newly derived check file is then compared 
against the original check file provided by the 
engineering department at 46. If for a particular built 
machine the comparison is passed then the machine and the 
check file are released to a customer at 48. If the 
comparison is failed then error listings are provided at 
SO and the built configuration is checked and adjusted at 
52. Flow then passes again to the compilation of a check 
file from the adjusted configuration at 44 and further 
comparison against the original check file at 46. 

At a customer site, the built configuration is 
installed 5 1. A check file is then generated from the 
installed oif ic/uration at 5 6 using the same methods as 
used at manufacture. This is done using software 
provided wit^ the check file which includes software to 
run the chectsiam logic required to derive the checksum 
data stored for the firmware routines and for the files 
in the softwa. g stack. This can be provided as an 
internal diagnostic tool or Cc.n be run from an external 
machine. 

A newly compiled check file is then compared and run 
against the original check f i i 3 at 58. If the comparison 
is passed then the installatioa is approved at 60. If it 
is failed, then error listings are provided at 62 and the 
supplier advised at 64 so that remedial action can be 
taken for the particular configuration. 

The check file described above, can be used only to 
check hardware, or only to check firmware, or only to 
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check the software stack, at any stage in the process. 
Alternatively, any combination of these three could be 
• checked at any stage. 

The checksum data used with the software stack is 
5 particularly important since software is frequently 
updated. Thus, the software installed at tha 

manufacturing stage may not be the same software as was 
originally specified by the engineering department and on 
which the configuration is based. 
10 The checksum data for each file will include: 

file name 
checksum 
file size 

time of last modification 
15 file type. 

Other information can also be inc-.luded. 
At the manufacturing stage, where a plurality of 
similar installations are being built, statistical 
analysis on errors can identify systematic problems in 
20 the manufacturing process. Thus, it will soon become 
apparent if software has changed since the check file 
being used was first generated. Changes in firmware and 
hardware can happen at any time and these also can be 
identified by statistical analysis of errors in the 
,.c- comparison stage. In instances where a customer is 
Installing equipment itself, the comparisons shown in 
fig-- re 6 are run and a list of hardware, firmware and 
3of-.- '.re configurations produced to send back to the 
. jturer for checking. 
30 Furthermore, a customer is able to check software 

updates against the original check file provided with the 
installed system to determine exactly what parts of the 
installed system have been changed by updates. This 
useful in analysing problems at an installation. 



is 
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Although method and systems consistent with the 
present invention have been described with reference to 
the embodiment above, those skilled in the art will know 
of various changes in form and detail which may be made 
5 without departing from the present invention as defined 
in the appended claims and their full scope of 
equivalence . 



Claims 



1. A method for checking a computer system conf iguraf.ion 
comprising the steps of: 

providing a first check file with a computer 
system configuration; 

deriving a second check file from the computer 
system configuration; 

comparing the first and second check files; and 

approving the computer system configuration in 
dependence on the results of the comparison. 

2. A method according to claim 1 in v/hich the check file 
includes data relating to a hardware portion of the computer 
system configuration . 

3. A method according to claim 1 in which the checK -'flie 
includes data relating to a firmware portion of the computer 
system configuration, 

4. A method according to claim 1 in which the check file 
comprises data relating to a software portion of the 
computer system conf iguration. 

3, A method according to claim 4 in which the step of 
deriving the check file comprises the step of deriving 
ciiecksuiri data from said software portion. 

6. A -o.thod according to claim 5 in which the step of 
uV • ; . ^ checksuiti data comprises the step of deriving 
cho- .c>um data for each file in the software configuration. 

7. A computer program product comprising a first check 
file ai;d executable computer code which when loaded on a 
computer cause it to execute the steps of: 
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deriving a second check file from a computer 
system configuration corresponding to the configuration from 
which the first check file was derived; 

comparing the first and second check files; and 
5 approving the computer system configuration in 

dependence on the result of the comparison. 

8 . A computer programme product according to claim 7 in 
which the first and second check files comprise checksum 
data derived from a software portion of the computer system 

10 configuration - 

9. A computer program product according to claim 7 and 8 
stored wii:hin a computer system. 

10. A compucer system comprising a computer with a 
predetermined configuration, and a computer program product 

i*^. according to claim 7 or 8 . 

11- A method rur cr^ecking a specification of a computer 
system configuration coinprising the steps of: 

providing a fJrst check file with the 
specification ; 

20 deriving \ second check file from the 

specification; 

comparing the first and second check files; and 
approving the i^pecif ication xn dependence on the 

results of the comparison. 

25 12. A method according to claim 11 in which the first check 
file includes checksum data derived from a software portion 
of the specification , and the step of deriving the second 
check file includes the step of deriving checksum data from 
the software portion of the specification. 

30 13. A method of manufacturing a computer system 

configuration including the steps of checking a manufactured 
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computer system configuration according to the method of any 
of the claims 1 to 6. 

14. A method for checking a computer system configuration 
after installation for a customer comprising the steps of: 

r providing a first check file with the computer 

system configuration; 

deriving a second check file from the computer 
system configuration after installation; 

comparing the first and second check files; and 
10 approving the installation in dependence on the 

results of the comparison, 

15. A method according to claim 14 in which the first and 
second check files each include checksum data. 



Ama„d™.„„ „ ^^^^ ^^^^ ^ ^^^^^ 



1. A method for checking a computer system 
configuration comprising the steps of: 
5 specifying a set of customer'' s requirements for a 

computer system configuration; 

designing a computer system configuration meeting 
the specified -requirements; 

generating a first check file relating to the 
0 designed computer system configuration; 

t>uilding the designed computer system 
configuration; 

deriving a second check file from the built 
computer system configuration; 
5 coniparing the first and second check files; and 

approving the built computer system configuration 
in dependence on the results of the comparison. 

2. -A method according to claim 1 in which the first 

) check file includes data relating to a hardware portion 
of the designed compater system configuration. 

3. A method according t.o claim 1 in which the first 
check file includes data relating to a firmware portion 
of the designed computer system configuration. 

4- A method according to claim 1 in which the first 
check file comprises data relating to a software 
portion of the designed computer system configuration. 

5. A method according to claim 4 in which the step of 
generating the first check file comprises the step of 
generating checksum data from said software portion. 



6. A method according to claim 5 in which the seep of 
generating checksum data comprises the step of deriving 
checksum data for each file in said software portion. 

7 . A method according to claim 1 in which the second 
check file includes data relating to a hardware portion 
of the built computer system configuration. 

S . A method according to claim 1 in which the second 
check file includes data relating to a firmware portion 
of the built computer system configuration. 

9. A method according to claim 1 in which the second 
check file comprises data relating to a software 
portion of the built computer system configuration. 

10. A method according to claim 9 in. which ;-.he step of 
generating the second check file comprises the stop of 
generating checksum data from said 3oftware portion. 

11. A m.ethod according to claim 10 in which the step 
..,f generating checksum data comprises the step of 
doiiving checksum data for each file in said software 
poi; uion . 

12. A mei-hod for checking a computer system 
'J on. Cig J ration comprising the steps of: 

■ specif ifii.g a set of customer's requirements for a 

computer syav.en. configuration; 

designir:g .',omputer system configuration meeting 

the spet:if-"i'-. ■ re-qairements ; 

generat:-r.g a first check file relating to the 

designed computer system configurations- 
building and installing the designed computer 

systom conf igurarion; 



deriving a second check file from the installed 

computer system configuration; 

comparing the first and second check files; and 
approving the installed computer system 

configuration in dependence on the results of the 

comparison, 

12 . A method according to claim 12 in which the first 
check file includes data relating to a hardware portion 
of the designed computer system configuration. 

14 . A method according to claim 12 in which the first 
check file includes data relating to a firmware portion 
of the designed computer system configuration. 

15- A method according to claim 12 in which the first 
check file comprises data relating to a software 
portion of the designed computer system configuration. 

16, A meLhod according to claim 15 in which the step 
of generating the flrsi: check file comprises the step 
of generating checksum data fi-oir said software portion. 

17- A method according to claim 16 in which the step 
of generating checksum data -.-.omprises the step of 
deriving checksum data for eacii file in said software 
portion . 

18. A method according to claim 12 in which the second 
check file includes data relating to a hardware portion 
of the installed computer system configuration, 

19. A method according to claim 12 in which the second 
check file includes data relating to a firmware portion 
of the installed computer system configuration. 



20. A method according to claim 12 in which the second 
check file comprises data relating to a software 
portion of the installed computer system configuration. 

21. A method according to claim 20 in which the step 
of generating the second check file comprises the step 
of generating checksum data from said software portion. 

22. A method according to claim 21 in which the step 
of generating checksum data comprises the step of 
deriving checksum data for each file in said software 
portion. 
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